Fix improper usage of constrained
breaking type inference
#13779
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In multiple places, we had code equivalent to the following pattern:
which lead to subtype checks directly involving the TypeParamRefs of the
constrained type lambda. This commit uses the following pattern instead:
which substitutes the TypeParamRefs by the corresponding TypeVars in the
constraint. This is necessary because when comparing
TypeParamRefs in isSubType:
isSubTypeWhenFrozen
which prevents further constraints from beingadded (see the added stm.scala test case for an example where this
matters).
been gc()'ed, there is no way to find the instantiation corresponding
to the current TypeParamRef anymore.
There is one place where I left the old logic intact:
TrackingTypeComparer#matchCase
because the match type cachinglogic (in
MatchType#reduced
) conflicted with the use of TypeVars sinceit retracts the current TyperState.
This change breaks a test which involves an unlikely combination of
implicit conversion, overloading and apply insertion. Given that there
is always a tension between type inference and implicit conversion, and
that we're discouraging uses of implicit conversions, I think that's an
acceptable trade-off.